Program-Data Combining System

ABSTRACT

Methods for securing at least one program application and data associated with the program application are herein described. In one embodiment, the method includes compressing the program application and data associated with the program application into a program-data combine having a compressed format and storing the program-data combine on a program-data combine computer.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Application Ser.No. 60/931,153, filed on May 21, 2007, the entire disclosure of which ishereby incorporated into this disclosure.

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR DEVELOPMENT

Not applicable.

NAMES OF PARTIES TO A JOINT RESEARCH AGREEMENT

Not applicable.

REFERENCE TO A “SEQUENCE LISTING,” A TABLE, OR A COMPUTER PROGRAMLISTING APPENDIX SUBMITTED ON A COMPACT DISC AND AN INCORPORATION BYREFERENCE OF THE MATERIAL ON THE COMPACT DISC

Not applicable.

BACKGROUND

1. Field of the Invention

The present invention relates generally to a program-data combiningsystem. More specifically, but not by way of limitation, the inventionrelates to storage and retrieval of programs and data as a single unit.

2. Brief Description of Related Art

Programs are a set of instructions developed to accomplish a certainobjective. Generally, programs operate on input data and stored data toaccomplish the desired result. The output data produced as a result iseither stored or provides instructions to external device(s) for furtheraction.

The bifurcation between programs and data provides great flexibility.For example, one program may be able to operate on several differentsets of data or several different programs may operate on the same data.With this flexibility, however, there is vulnerability.

Within bifurcated programs and data, a “rogue program” or a virus mayoperate on any file containing the programs and/or data in the systemand corrupt the file. Such viruses may flood the computer system withspurious data, place the processor in a “loop,” or other similarmalfeasant acts that hinder the processor from productive work.

Currently within the field of computer technology, immunity from attacksby computer viruses is a daily threat. Security in most systems is notbuilt in, but instead added on. For example, currently implementedsecurity systems include firewalls, anti-virus software, and othersimilar mechanisms.

One of the principle reasons attacks are so prevalent is the ability toexploit the weakness in the separation between programs and data. Thisseparation between the programs and data is an easy target to prey upon.

Within the art, separation of programs and data has been necessitated bythe fact that programs and data can get arbitrarily large. As such,associating programs and data as a single entity becomes a practicalimprobability due to storing and transmission considerations. Greatstrides have been made, however, in the compression of programs and dataincreasing the feasibility of joining programs and data for storage andtransmission.

For example, compression of data as disclosed in U.S. Pat. No.7,298,293, entitled, “METHOD OF ENCODING DATA”, produces a compressedset of data that is only a small fraction of the size of the programand/or data that it operates on. See U.S. Pat. No. 7,298,293, filed onMay 18, 2006, the entire contents of which is hereby incorporated intothis disclosure. Subsequent provisional applications disclosedecompression of this compressed set to reproduce the original programand/or data. See U.S. Provisional Patent No. 61/016,022, filed on Dec.21, 2007, and U.S. Provisional Patent No. 61/038,527, filed on Mar. 21,2008, the entire contents of which are hereby incorporated by referencein their entirety.

The use of these compression techniques, and/or other similarcompression techniques, provide a mechanism for combining program anddata into a single entity for storage and transmission.

BRIEF SUMMARY OF THE EMBODIMENTS

The present invention advances the concepts of securing computersystems. In one embodiment, programs and data are treated as a unit.This unit is derived in a compressed format and referred to as aprogram-data combine. Within a program-data combine, a program may onlyoperate and/or modify the data that is associated with the program. Forexample, a first program and its data are compressed to form aprogram-data combine. The program-data combine is stored on theprogram-data combine computer. A second program and/or external computerrequests use of the data within the first program. The program-datacombine computer provides the data to the second program, but only as aprogram-data combine. The second program must have the needed softwareand/or hardware to decompresses the program-data combine, modify thedata, and recompress the program and data to provide a new version ofthe program-data combine to be sent back to the program-data combinecomputer leaving the original program-data combine unaltered. Generally,the program within the program-data combine is only operable on the dataspace attached to it in the program-data combine computer.

Further, the program-data combine capitalizes on the efficiencies gainedfrom the compression and decompression of data. Generally, program-datacombines are received from sources external to the program-data combinecomputer. Having the program-data combines in a compressed format allowsfor efficient transmission and storage of programs and data.

BRIEF DESCRIPTION OF SEVERAL VIEWS OF THE DRAWINGS

So that the above recited features and advantages of the presentinvention can be understood in detail, a more particular description ofthe invention, briefly summarized above, may be had by reference to theembodiments thereof that are illustrated in the appended drawings. It isto be noted, however, that the appended drawings illustrate only typicalembodiments of the invention and are therefore not to be consideredlimiting of its scope, for the invention may admit to other equallyeffective embodiments.

FIG. 1 is a block diagram of one embodiment of a program-data combinecomputer system.

FIG. 2 is a flow chart of one embodiment of a method for powering upcomponents for use in the program-data combine computer system of FIG.1.

FIG. 3 is a flow chart of one embodiment of a method for service requestprocessing for use in the program-data combine computer system of FIG.1.

FIG. 4 is a flow chart of one embodiment of a method for securityclearance processing for use in the program-data combine computer systemof FIG. 1.

FIG. 5 is a flow chart of one embodiment of a method for providing dataand output processing for use in the program-data combine computersystem of FIG. 1.

FIG. 6 is a flow chart of one embodiment of a method for providing powerdown processing for use in the program-data combine computer system ofFIG. 1.

DETAILED DESCRIPTION OF THE EMBODIMENTS

Present embodiments of the invention are shown in the above-identifiedfigures and described in detail below. In describing the embodiments,like or identical reference numerals are used to identify common orsimilar elements. The figures are not necessarily to scale and certainfeatures in certain views of the figures may be shown exaggerated inscale or in schematic in the interest of clarity and conciseness.

Referring now to the figures, and in particular to FIG. 1, shown thereinand designated by reference numeral 10 is a program-data combinecomputer for interrelating program and data information. Theprogram-data combine computer 10 provides a mechanism for removing thebifurcation of programs and data in the current art. The program-datacombine computer may also herein be referred to as a spinner 10.

In the spinner 10, programs and data are treated as one entity known asthe program data compact (PDC). Only programs within the PDC maymanipulate the data within the PDC. Generally, the program-data compactis received, acted upon, stored, and/or transmitted in a compressedformat.

Generally, the program-data combine computer 10 includes a directorprocessing unit (DPU) 12 that controls the functions of spinner 10. TheDPU 12 is capable of activating and/or deactivating any of thecomponents within the spinner 10. The DPU 12 may be any computationaldevice capable of receiving and providing instructions to othercomputational devices.

The DPU 12 communicates with a data management unit (DMU) 14. The DMU 14is capable of performing memory management functions required within thespinner 10. The DMU 14 may be any memory storage device capable ofstoring PDCs.

The DPU 12 within the spinner 10 oversees a variety of processes such asthe following six separate processes to provide and utilize the PDC: thepower up sequence, a service request process, security clearanceprocess, data processing, output processing, and a power down sequenceand other functions as may be warranted.

The power up sequence provides the operating system and memory at thetime of the last power down sequence. During this process, the DPU 12communicates directly with a compression/decompression pump (C/D/pump)16. Generally, the C/D pump 16 performs the process of compressingprograms and/or data and decompressing such programs and/or data ondemand. In the power up process, the C/D pump 16 decompresses data froma kernel to obtain the operating system and memory at the time of thelast power down of the spinner 10.

Once the spinner 10 is powered up, the DPU 12 can coordinate servicerequests from external sources through the service request process.Service requests are generally provided by wireless sources and/ordirect sources.

The wireless sources are managed through a wireless processing unit(WPU) 20. The WPU 20 receives signals from wireless sources such asradio, TV, local area wireless networks, and/or the like.

The direct connect sources are managed through an input processing unit(IPU) 22. The IPU 22 manages data input from devices in directcommunication with the spinner 10. Devices in direct communication withthe spinner 10 may include a keyboard, mouse, telephone line, fiberoptic line, and/or the like.

Certain service requests may require security clearance. A securityclearance unit (SCU) 24 manages security clearance aspects for theservice requests acted upon by various components of the spinner 10.

A service request cleared by the SCU 24 is able to be processed by acentral processing unit (CPU) 26 within the spinner 10. The CPUgenerally abstracts each instruction within an active program andexecutes it until completion. An arithmetic logic unit (ALU) 28 providesassistance to the CPU 26 during execution of the active program byperforming the arithmetic and logic functions encoded within the activeprogram.

Output provided by execution of the program is processed by an outputprocessing unit (OPU) 30. The OPU 30 manages the output and provides theoutput to other devices external to the spinner 10. For example, the OPU30 may provide output from the executed program to printers, faxmachines, telephone line, external spinner, and/or the like.

Interaction between components of the spinner 10 illustrated in FIG. 1provides for the storage, modification, transmission, and retrieval ofthe PDC. Each of the processes designed to provide and utilize the PDCare described in further detail herein below.

1. Power-Up Sequence

FIG. 2 is a block diagram of one embodiment of power up components foruse in the spinner 10 of FIG. 1. The power-up sequence generallyprovides the operating system and memory from the last power-downsequence.

Initially, the DPU 12 deactivates all major components within thespinner 10. After deactivation, the DPU 12 provides an activation signalto the DMU 14. The activation signal provides the DMU 14 a specificmemory address for the power-up sequence known as the “Initial ProgramLoad.”

The DMU 14 searches and provides the data within the kernel 18 to theC/D pump 16 and includes a request to perform an initial load. The C/Dpump 16 decompresses the data from the kernel 18. Decompressing datafrom the kernel 16 provides an operating system 32 and user memory 34 atthe time of the last power down sequence. The operating system 32 anduser memory 34 at the time of the last power down sequence is loaded bythe C/D pump 16 to the memory address, provided by the DMU 14 therebyaccomplishing an “Initial Program Load”. The operating system 32 anduser memory 34 are then capable of being displayed on an external device36. For example, the operating system 32 and user memory 34 may bedisplayed on a monitor. Once the operating system 32 and user memory 34are loaded starting at the designated memory location, the DMU 14signals the DPU 12 the “Initial Program Load” and therefore the power upsequence is complete.

2. Service Request Process

FIG. 3 is a block diagram of one embodiment of a method for servicerequest processing. Generally, a service request process for the spinner10 may be provided by several sources. The sources may be broadlygrouped into two categories: wireless and direct connect.

The wireless sources are managed through the WPU 20. The WPU 20 receivessignals from wireless sources such as radio, TV, local area wirelessnetworks, and/or the like.

The direct connect sources are managed through the IPU 22. The IPU 22manages data input from devices in direct communication with the spinner10. Devices in direct communication with the spinner 10 may include akeyboard, mouse, telephone line, fiber optic line, and/or the like.

The DPU 12 receives at least one request for service for the spinner 10from the WPU 20 and/or the IPU 22. The DPU 12 catalogs the request forservice on a service request stack 38. In one embodiment, the catalogprovides a mechanism for prioritizing two or more requests for servicefrom the spinner 10. The catalog may include one or more prioritizingcriteria for the two or more requests for service. Examples ofprioritizing criteria may include time, memory space, and/or the like.

A stack pointer 40 selects the request for service within the requeststack 38. The stack pointer 40 places the request for service in arequest register 42.

If the request for service requires security clearance, the DPU 12signals the SCU 24 to request security clearance as illustrated in FIG.4. Specifically, the DPU 12 inserts information into the requestregister 42 if the request for service requires security clearance orfurther security clearance processing.

3. Security Clearance Processing

FIG. 4 is a block diagram of one embodiment of a method for securityclearance processing. The SCU 24 obtains information from the requestregister 42 on the request for service through a token 44. Generally,tokens 44 contain security clearance requirements of PDC in the form ofinformation and/or procedures. For example, tokens 44 may contain thelicensing information regarding the specific application, passwordauthentication procedures, instructions regarding the copying and/ordissemination of data, special clearance needs required before theexecution of the program is allowed and/or other similar information.Additionally, tokens 44 may contain PDCs requiring execution.

The SCU 24 receives information from a specific token 44 a. The specifictoken 44 a stores information related to the request for service. TheSCU 24 determines whether all of the procedures outlined in the token 44a are met. For example, if the token 44 a contains specific informationregarding a password, the SCU 24 determines whether the password hasbeen authenticated.

Once all of the procedures outlined in the token 44 a are met, the SCU24 provides the service request to a cleared request stack 46. If any ofthe procedures as outlined in the token 44 are not satisfied, the SCU 24provides the request for service to a denied request stack 48. Ifadditional procedures as outlined in the token 44 require furtherprocessing, the SCU 24 provides the request for service to a pendingrequest stack 50.

Once the SCU 24 provides the request for service to either the clearedrequest stack 46, the denied request stack 48, or the pending requeststack 50, the SCU 24 may provide a signal to the DPU 12 regarding thestatus of the request for service. The DPU 12 receives the status signaland dispatches at least one message indicating the status of the requestfor service to the source that initially requested service.

If the request for service is placed in the cleared request stack 46,the DPU 12 provides the request for service into an execution register52 and signals the CPU 26 to process the request for service asillustrated in FIG. 5.

4. Data Processing/Output Processing

FIG. 5 is a block diagram of one embodiment of a method for providingdata and output processing. Generally, the CPU 26 receives the requestfor service from the execution register 52 and signals the DMU 14 toretrieve the required PDC 54. The PDC 54 may be on the cleared requeststack 46 (not illustrated in FIG. 5) or the PDC may be stored within thesystem memory (not illustrated in FIG. 5).

The DMU 14 retrieves the token 44 a and processes the token 44 a byplacing a time stamp on the token 44 a, tagging the token 44 a as“before copy,” and/or other similar processing techniques known withinthe art. The DMU 14 stores the token 44 in the main memory of the PDC 54as part of user data.

The PDC 54 is then sent by the DMU 14 to the C/D Pump 16, or similarpump, capable of decompressing the PDC 54 from its compressed format.Decompressing the PDC 54 will expand the PDC 54 to provide the programand associated data in a decompressed format. The C/D Pump 16 places thedecompressed program and data information in the main memory of thespinner 10 at a location requested by the DMU 14. The C/D Pump 16 thensignals the CPU 26 to commence execution of the decompressed program andoperate on the decompressed data.

As the program execution continues, the CPU 26 and the ALU 28 generatestatistics 56 on the progress of the program to monitor programexecution. Such statistics 56 may include information on whether therequest for memory has exceeded a certain threshold, if the program isin a loop, and/or other similar information. Based on these statistics56, a signal may be sent by the DPU 12 in order to disable the CPU 26and/or ALU 28 and terminate execution of the program if needed.

At the termination of program execution, the CPU 26 signals the C/D Pump16 to recompress the program and data into the PDC 54 format. The CPU 26may also instruct the C/D Pump 16 to create an “after copy” of the token44 a with the resulting PDC attached. The “after copy” of the token 44 ais associated with the “before copy” of the token 44 a and stored in themain memory of the spinner 10 as part of the user data. If output wasrequested and cleared at the termination of the program execution, theoutput may be provided to an output request stack 58 in the form of the“after copy” of the token 44 a.

The CPU 26 then signals the DPU 12 that program execution is complete.At this point, the DPU 12 directs the OPU 30 to process the outputderived from the program execution. Output may be processed by the OPU30 according to security clearance restraints instructed within thetoken 44 a and provided to external devices 60 such as a parallel port,USB port or serial port for transmission purposes.

Data processing and output processing are repeated for every request forservice on the cleared request stack 46. When all such requests forservice on the cleared request stack 46 have been processed, the spinner10 goes into a wait state until additional requests are available to beserviced.

5. Power Down Sequence

FIG. 6 is a block diagram of one embodiment of a method for providingpower down processing. Generally, the DPU 12 disables various componentsof the spinner 10 and signals the DMU 14 to initiate a shut down of thecomponents within the spinner 10.

The DMU 14 sends a signal request to the C/D Pump 16 to compress theoperating system 32 and user data 34 within the main memory. Aspreviously discussed, user data consists of tokens 44 stored in the mainmemory 62 of the spinner system 10 may include the “before copy” and the“after copy.” The operating system 32 and the user data may becompressed together or compressed separately as needed for storagewithin the kernel 18.

During the power down sequence, the C/D Pump 16 consolidates informationinto an archived operating system 32 a and archived user data 34 a toprovide back-up copies of the operating system 32 and user data 34.Generally, the archives 32 a and 34 a would normally be stored in anon-volatile memory (e.g. hard drive or flash memory) device as back upin case the operating system and user data are damaged or lost.

From the above description, it is clear that the present invention iswell adapted to carry out the objects and to attain the advantagesmentioned herein, as well as those inherent in the invention. Althoughthe foregoing invention has been described in some detail by way ofillustration and example, it will be apparent to those skilled in theart that certain changes and modifications may be practiced withoutdeparting from the spirit and scope of the present invention, asdescribed herein. Thus, the present invention is not intended to belimited to the embodiments shown, but is to be accorded the widest scopeconsistent with the principles and features described herein.

1. A method for securing at least one program application and dataassociated with the program application, comprising: compressing theprogram application and data associated with the program applicationinto a program-data combine having a compressed format; the programapplication being adapted to only operate on the data associated withthe program application; storing the program-data combine on aprogram-data combine computer.
 2. The method of claim 1, furthercomprising the step of: transmitting the program-data combine from theprogram-data combine computer to an external computer, the externalcomputer storing and transmitting the program-data combine in thecompressed format.
 3. The method of claim 2, further comprising thesteps of: decompressing, by the external computer, the program-datacombine to enable the program application to operate on the associateddata in a decompressed state; and, recompressing, by the externalcomputer, the program application and the associated data to provide amodified program-data combine distinct from the original program datacombine for storage and transmission.
 4. The method of claim 2, furthercomprising the step of: validating the program-data combine byidentifying at least one security feature compressed within theassociated program-data combine.
 5. The method of claim 4, wherein thesecurity feature is a time stamp identifying the before and afterexecution of the program by the external computer.
 6. The method ofclaim 5, further comprising the step of: storing the program-datacombine within a kernel, wherein the program and the associated data arecompressed and stored as separate entities within the kernel.